Method for processing a request for access to a data network

ABSTRACT

A network access arrangement for connecting an end user&#39;s computer to the Internet includes a network access server and a proxy server. When an end user requests to be connected to the Internet, the network access server forwards the access request to the proxy server. The proxy server authenticates some requests itself but forwards other requests to authentication servers for authentication. After receiving a response from one of the servers, the proxy server forwards the response to the network access server. If the proxy server does not receive a response from one of the authentication servers, it follows a default procedure. This can be to authenticate the request in the proxy server or simply to accept the request. The proxy server has a counter associated with each of the servers. Each time the proxy server receives a response from one of the servers, it decrements the appropriate counter. Each time it does not receive a response, it increments the appropriate counter. When one of the counters reaches a threshold value, the proxy server then follows the default procedure for a pre-set number of requests which would normally be forwarded to the appropriate server. After following the default procedure for this predetermined number of access requests, the proxy server forwards the next access requests, which would normally be forwarded to the relevant server, to that server.

BACKGROUND OF THE INVENTION

1. Technical Field

This application is the US national phase of international applicationPCT/GB00/04551 filed 29 Nov. 2000 which designated the U.S.

This invention relates to a method of processing a request at an accessserver arrangement from a data terminal operated by an end user foraccess to a data network, and to a network access server and networksincluding such servers.

2. Related Art

The function of such an access server arrangement is to connect a dataterminal, for example a personal computer, operated by an end user to adata network, for example the public Internet. Typically, such an accessserver arrangement comprises a network access server which receivesaccess requests and provides connections to a data network and anauthentication server which can be accessed by the network accessserver.

In a simple set up, when a network access server receives an accessrequest, it obtains details from the end user relating to the end usersuch as a user identifier and a password. It then sends these details tothe authentication server which authenticates the request by checkingthese details against expected details which have been previouslyregistered by the end user. If the details received from the end usercorrespond to the expected details, then the request is accepted and theend user's data terminal is connected to the data network. If thedetails are not as expected, then the access request is rejected.

In a modification of the simple set up, for some or all services, theauthentication server acts as a proxy server. For each of theseservices, when the proxy server receives an access request from thenetwork access server, it forwards the request to the relevantauthentication server. This authentication server then checks thedetails. If the details received correspond to the expected details,then the authentication server sends an access accept message to theproxy server. If the details are not as expected, then theauthentication servers sends an access reject message back to the proxyserver. The proxy server then forwards the access accept or accessreject message to the network access server. If the network accessserver receives an access accept message, then it connects the dataterminal operated by the end user to the data network. If it receives anaccess reject message, then access to the data terminal is refused.

However, if an authentication server fails to respond to an accessrequest message with either an access accept message or an access rejectmessage, the consequence can be that the access request message from thedata terminal operated by the end user is not dealt with in asatisfactory manner.

BRIEF SUMMARY OF THE INVENTION

According to a first aspect, the invention provides a method ofprocessing a request at an access server arrangement from a dataterminal operated by an end user for access to a data network, saidmethod comprising the steps of:

receiving a request from the data terminal at the access serverarrangement for access to the data network;

in the event that a predetermined criterion is not satisfied:

-   -   (i) attempting to forward the access request to an        authentication server;    -   (ii) if a response is received from the authentication server,        dealing with the access request in accordance with the response;        and    -   (iii) if a response is not received from the authentication        server, dealing with the access request in accordance with a        default procedure; and

in the event that the predetermined criterion is satisfied, dealing withthe access request in accordance with a default procedure.

This aspect of the invention helps ensure that access requests arehandled in a satisfactory manner.

In one embodiment of the invention, the method includes the followingsteps:

if a response is not received from an authentication server, changingthe value held in a counter by one unit in one direction; and

if a response is received from an authentication server, changing thevalue held in the counter by one unit in the other direction; and

the predetermined criterion is reached when the value held in thecounter has progressed in said one direction to a predeterminedthreshold.

Preferably, in the event that the counter has reached said predeterminedthreshold, the method includes the steps of performing the defaultprocedure for a predetermined number of times, then changing the valueheld in the counter by one unit in the other direction, and then makingan attempt to forward the next access request to the authenticationserver.

BRIEF DESCRIPTION OF THE DRAWINGS

This invention will now be described in more detail, by way of example,with reference to the drawings in which:

FIG. 1 is a block diagram showing an access server arrangement forconnecting computers operated by end users to the public Internet;

FIG. 2 is a graph showing the sequence of operations which are followedin the access server arrangement of FIG. 1 in authenticating an accessrequest from an end user;

FIG. 3 is a graph showing the sequence of operations which are followedin the access server arrangement of FIG. 1 providing an accountingrecord of an end user's session on the Internet;

FIG. 4 is a block diagram showing a modification to the arrangement ofFIG. 1 in which access requests can be forwarded from a proxy server tothree authentication servers;

FIGS. 5 and 6 are tables which are used by the proxy server of FIG. 4 inhandling access requests;

FIG. 7 is a flow chart of a series of operations which are performed bythe proxy server of FIG. 4 in handling an access request;

FIG. 8 is a flow chart of another series of operations which areperformed in the proxy server of FIG. 4 in handling an access request;

FIG. 9 is a flow chart of a set of operations performed by the proxyserver of FIG. 4 when handling an access accept message from anauthentication server; and

FIG. 10 is a block diagram of another arrangement for connectingcomputers operated by end users to the public Internet.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

Referring now to FIG. 1, there is shown an arrangement for connecting adata terminal in the form of a computer 10 operated by an end user tothe public Internet 12. Although this invention will, by way of example,be described with reference to the public Internet, it is to beappreciated that the invention could be used for gaining access to othertypes of data network. In this specification, the term “end user”indicates an individual person who wishes to use his or her computer togain access to the public Internet or another data network.

As shown in FIG. 1, the end user's computer 10 can be connected to thepublic Internet 12 through the public switched telecommunicationsnetwork (PSTN) 14, a network access server (NAS) 16 and a firewall 18.In this example, the end user's computer 10 has a modem for convertingthe digital signals generated in the computer 10 to modulated analoguesignals for transmission through the PSTN 14 and also for convertingmodulated analogue signals received from the PSTN 14 into digitalsignals for use within the computer 10. The NAS 16 has a bank of modemsfor answering calls from end user's computers. By way of modification,the invention can also be used for providing access to the publicInternet where the connection between the end user's computer and theNAS is digital, for example, using integrated services digital network(ISDN) technology or asynchronous digital subscriber loop (ADSL)technology. Where a digital connection is used, modems are not needed.Network access servers are presently available from several vendorsincluding Cisco, Ascend and Lucent. Another name for a network accessserver is Remote Access Server. For reasons of simplicity, FIG. 1 showsa single network access server. In practice, in order to provide thedesired capacity, there is usually a set of network access servers at asingle location.

As is well known, in the public Internet 12, data packets are routedusing the well-known Internet Protocol (IP) and transported using thewell-known connection-oriented Transmission Control Protocol (TCP). Thecomputer 10, NAS 16 and firewall 18 are all capable of receiving andtransmitting data packets which use these protocols.

As shown in FIG. 1, the firewall 18 is also connected to a private datanetwork 20. A registration server 22, an authentication and accountingserver 24 and a mail server 26 as well as other servers, not shown, arealso connected to network 20. In the network 20, data packets are routedusing IP. Between the NAS 16 and the registration server 22 and the mailserver 26, packets are transported using TCP. However, to avoid delays,between the NAS 16 and the authentication and accounting server 24, thetransport protocol is the well known connectionless User DatagramProtocol (UDP). The mail server 26 uses two well known higher levelprotocols. Between the mail server 26 and other mail servers, the SimpleMessage Transport Protocol (SMTP) is used. Between the mail server 26and computers operated by end users, Post Office Protocol number 3(POP3) is used. The mail server 26 will not be described further as itdoes not form part of this invention.

Between the NAS 16 and the authentication and accounting server 24, ahigher level protocol known as the Remote Authentication Dial-In UserService (RADIUS) is used. This protocol is used to pass attributesbetween the NAS 16 and the authentication and accounting server 24. Auser password and a user identifier are examples of such attributes.Each message transmitted using the RADIUS protocol serves a particularpurpose and the purpose is specified in the message. A request for auser to be given access to the Internet 12 is an example of such apurpose. The RADIUS protocol was devised by Livingston Enterprises Inc.and it is becoming an industry standard for Internet accessauthentication and accounting. Authentication is a process of verifyinga user's details to decide whether a user can be given access to theInternet. Accounting is a method of collecting information on the use ofthe Internet by an end user which can be used for billing, auditing andreporting.

The firewall 18 protects the NAS 16 and the servers 22, 24 and 26 fromintrusion from users of the Internet 12.

In this example, the NAS 16, the firewall 18 and the servers 22, 24 and26 form an access server arrangement and belong to a singleorganisation. Because this organisation is responsible for providingaccess for end users to the Internet, the organisation is known as anInternet service provider. However, as will be described in more detailbelow, the server 24 can be modified so that it can also “proxy” orforward access request messages to other authentication and accountingservers. These other servers may belong to the same Internet serviceprovider as the authentication server 24 or to other Internet serviceproviders. Alternatively, the other servers may belong to the sameorganisation as the authentication server 24 but be managed separatelywithin that organisation. Where an access request message is forwardedto another server, then that server, rather than the server 24, isresponsible for authentication or accounting. Where the server 24 isserving the function of forwarding messages, rather than responding tothe messages itself, it is referred to as a proxy server.

Before an end user can gain access to the Internet 12, the end user isusually given a user identifier and a password. The user identifier andpassword are issued, online, by the registration server 22 and thesedetails are held in a database, not shown, which can be accessed by theauthentication and accounting server 24. Where an Internet serviceprovider requires an end user to have a user identifier and a password,these details are checked by the authentication and accounting server24, during an authentication phase, before giving an end user access tothe Internet 12. Some Internet service providers do not require the enduser to have a user identifier or a password. In the case of suchInternet service providers, the authentication and accounting server 24usually checks some other detail, such as the number called by the enduser's computer, before permitting access to the Internet.

Where an end user has a user identifier and a password, the sequence ofevents which occur in responding to a request from the end user'scomputer for access to the Internet 12 will now be described withreference to FIG. 2.

When the end user wishes to access the Internet 12, the computer 10dials the NAS 16. The PSTN 14 then provides a link between the computer10 and the NAS 16. Traffic is carried over this link between thecomputer 10 and the NAS 16 using the Point-to-Point Protocol (PPP) andtwo further protocols which are the Link Control Protocol (LCP) and theInternet Protocol Control Protocol (IPCP). The LCP is responsible forconfiguring and testing the link between the computer 10 and the NAS 16and the IPCP is responsible for handling IP packets at each end of thelink and negotiating the compression technique to be used.

When the link has been configured and tested, the computer 10 sends arequest for service message to the NAS 16. The NAS 16 then sends achallenge message to the computer 10. The purpose of this message is toobtain the user's identifier and the user's password. On receiving thismessage, the end user enters his or her details on the computer 10 andthe computer 10 then transmits these details to the NAS 16 in a responsemessage. The password itself is transmitted using one of two protocols.These protocols are the Password Authentication Protocol (PAP) and theChallenge Handshake Authentication Protocol (CHAP). Both of theseprotocols provide some security but CHAP is more secure than PAP. Theseprotocols are well known and will not be further described.

When the NAS 16 has received these details, it transmits anaccess-request message containing these details received from the enduser to the authentication and accounting server 24. The access-requestmessage also contains further details, such as an identifier for the NAS16 itself and the calling party's telephone number of the telephone lineused by computer 10.

The server 24 then checks the details received from the NAS 16 againstdetails held in the database. If the user's details do not correspond tothe details held in the database, then the server 24 sends anaccess-reject message to the NAS 16, which then terminates the call. Ifthe details obtained from the computer 10 are as expected, then theserver 24 sends an access-accept message to the NAS 16. If the NAS 16receives an access-accept message, then it assigns an IP address to thecomputer 10, transmits this to the computer 10 in an assign IP addressmessage and then allows traffic to pass between the computer 10 and theInternet 12.

As mentioned above, some Internet service providers do not require anend user to have a user's identifier or password. When using a serviceprovided by such an Internet service provider, the sequence outlinedabove is modified as follows.

The computer 10 still sends a request for service message to the NAS 16and the NAS 16 still sends a challenge message to the computer 10.However, the response message from the computer 10 to the NAS 16 willnot contain a user identifier or a user password and so these detailsare not included in the access-request message from the NAS 16 to theserver 24. However, the access-request message may contain some otherinformation, for example the number dialled by the computer 10. Onreceiving the access-request message, the server 24 checks theinformation contained in the access-request message against expectedinformation. For example, it might check the number dialled by thecomputer 10 to see if the expected number was, in fact, dialled. If theinformation received from the NAS 16 corresponds to the expectedinformation, then an access-accept message is transmitted to the NAS 16,which then permits traffic between the computer 10 and Internet 12 asdescribed above. If the information received from the NAS 16 does notcorrespond to the expected information, the server 24 sends anaccess-reject message to the NAS 16. The NAS 16 then terminates thecall.

When an end user wishes to register with an Internet service provider,then during registration the sequence of events described above ismodified as follows. The end user's computer 10 still sends a requestfor service message to the NAS 16 and the NAS 16 still sends a challengemessage back to the computer 10. At this stage, the end user is unableto enter a user identifier or password and so the response messagecannot contain these details. These details are also absent from theaccess-request message sent by the NAS 16 to the server 24. As theaccess-request message contains neither a user identifier nor apassword, the server 24 interprets the access-request message as arequest for registration. It therefore sends an access-accept message tothe NAS 16 but the message contains an instruction to the NAS 16 toapply a filter to IP packets received from the computer 10. The NAS 16then assigns an IP address to the computer 10. The NAS 16 then permitstraffic from the computer 10 to pass through it but subject to thefilter. Normally, the filter would specify that only packets destinedfor the registration server 22, or received from this server, can passthrough the NAS 16. Consequently, the end user can then register withthe Internet service provider and thus obtain a user identifier andpassword.

Referring now to FIG. 3, immediately before the NAS 16 allows Internettraffic to pass between the computer 10 and the Internet 12, it sends anaccounting-start message to the server 24. The server 24 then logs thetime at which the session is commencing and certain other detailsrelating to the end user. It also sends an access-response message tothe NAS 16. The user's Internet session then proceeds. Immediately afterthe session has terminated, the NAS 16 sends an accounting-stop messageto the server 24. The server 24 then logs the time at which the sessionhas ended and sends an accounting-response message to the NAS 16.Accounting information is held for two purposes. Firstly, it providesbasic information which allows a service provider to issue usage-basedbilling. Secondly it provides an audit trail of the user's connectiontime, IP address and certain other details which may be needed for legalreasons.

As mentioned above, the server 24 can be modified so as to forwardaccess request messages to other servers for authentication andaccounting. Referring now to FIG. 4, there is shown an arrangement inwhich the server 24 can forward access request messages toauthentication server A (server 30), authentication server B (server 32)or authentication server C (server 34). Each of the servers 30, 32 and34 is capable of performing both authentication and accounting. Theserver 24 is still capable of authentication and accounting but will nowbe referred to as a proxy server as it is also capable of forwardingaccess request-messages. Servers A, B and C may belong to the sameInternet service provider as the Internet service provider which ownsthe NAS 16 and the proxy server 24 or to other Internet serversproviders. Alternatively, the servers A, B and C may belong to the sameInternet service provider as the NAS 16 and the proxy server 24 but bemanaged separately within that organisation. Although, by way ofexample, in FIG. 4 the proxy server 24 is capable of forwarding accessrequest messages to three other servers, it could of course be modifiedso as to forward such messages to a smaller or greater number ofservers. The proxy server 24 could also be arranged to instruct the NAS16 to form a tunnel to a home gateway. Home gateways are discussed belowwith reference to FIG. 10.

A simple procedure for handling access request messages in the proxyserver 24 will now be described. In this simple procedure, when theproxy server 24 receives an access request message from the NAS 16containing a user identifier, it splits the user identifier into a username part and a domain part. This simple procedure can only be usedwhere all user identifiers received by the NAS 16 follow the samepattern. An example of such a pattern is n@d, where n is the value ofthe user name and d is the value for the domain. After splitting up theuser identifier into two parts, the proxy server 24 consults a databasetable. For each of the possible domains, this table specifies the serverwhich is responsible for performing authentication and accountingoperations in response to an access request message. If the relevantserver is the proxy server 24 itself, it performs authentication andaccounting as described above. If the appropriate server is one of theservers A, B and C, the proxy server 24 forwards the access requestmessage to the appropriate one of these servers. The appropriate serverthen performs authentication and sends a response message to the proxyserver 24 which, in turn, forwards it to the NAS 16. The NAS 16 thenprovides or denies the connection as specified in the response message.The server which has performed the authentication operation alsoperforms the accounting operation.

As described above, the simple procedure is only capable of handlingaccess request messages in which all user identifiers follow the samepattern. Also, the simple procedure is limited to either performingauthentication and accounting in the proxy server 24 itself orforwarding the access request message to one of the servers A, B and Cfor authentication and accounting. There will now be described, withreference to FIGS. 5 to 7, an improved procedure for handling accessrequest messages in which the user identifiers can follow severaldifferent patterns. The improved procedure also provides morepossibilities for handling access request messages. These possibilitiesinclude re-writing a user identifier before forwarding an access requestmessage to another server, providing different servers forauthentication and accounting, the provision of a default server in theevent that a server is unable to perform either authentication oraccounting, and handling an access request message which does notinclude a user identifier or password.

Referring now to FIG. 5, there is shown a table which has five columns41-45 and five rows 51-55. Each of the rows 51-55 contains a rule whichspecifies how an access request message is to be handled by the proxyserver 24. The information which specifies how an access request messageis to be handled is contained in columns 43-45. When an access requestmessage arrives at proxy server 24, the relevant rule has to beidentified and the information for doing this is contained in columns 41and 42. The procedure for identifying the relevant rule will now bedescribed and this will be followed by an explanation of the variouspossibilities, specified in the rules, for handling access requestmessages.

When an access request message which contains a user identifier arrivesat proxy server 24, the pattern of the user identifier in the accessrequest message is compared with the patterns shown in column 41 (headed“Pattern”) for each of rows 51-54 in turn. In the example shown in FIG.5, the pattern shown in rows 51, 52 and 54 is of the type n@d and thepattern shown in row 53 is of the type n/d. When a match is foundbetween the pattern in the user identifier in the access request messageand a pattern in one of rows 51-54, the identified pattern is used tosplit the user identifier into the user name part and a domain part.

Next, for an access request message which contains a user identifier,the domain part of the user identifier is compared with the values givenin column 42 (headed “Specified Attribute”) for each of rows 51-54 untila match is found. The row in which the match is found is then identifiedas containing the rule which specifies the procedure for handling thisparticular access request message.

It should be noted that, in order to identify the relevant rule, boththe pattern of the user identifier in an access request message and thevalue of its domain must match, respectively, the pattern shown incolumn 41 and the value given for the domain in the same row in column42. For example, if a user identifier has a pattern n@d and the domainpart has a value bti.co.uk, then the relevant rule is specified in row54 rather than in row 53.

If the access request message does not contain a user identifier, then amatch will not be found for any one of the patterns in column 41 forrows 51-54. When a match is not found in any one of rows 51-54, thepattern of the calling number is checked against a pattern for thecalling number specified in column 41 of row 55. In this example, thespecified pattern is that the calling number is formed solely fromdigits. If a match is found between the pattern of the calling numberand the specified pattern, the calling number is compared with aspecified value in column 42 of row 55. If a match is found, then row 55is identified as containing the rule which specifies the procedure forhandling the access request.

The table shown in FIG. 5 could be expanded to include one or morefurther columns which contain values for further attributes. Where thereare one or more further columns, then the relevant row, and hence therelevant rule, will be identified when the value of the domain part ofthe user identifier contained in the access request message and also thevalues of the relevant further attributes also match the valuesspecified in these columns.

By way of modification, the table shown in FIG. 5 could contain rulesfor splitting up other attributes, for example the calling number, inthe access request message.

After the relevant row, and hence the relevant rule has been identified,then the proxy server 24 consults column 43 (headed Proxy UserIdentifier). The purpose of this column is to specify whether or not theuser identifier is to be written before forwarding an access requestmessage to another server. In this example shown in FIG. 5, in each ofrows 51, 52, 54 and 55, column 43 has an “=” sign. This denotes that theuser identifier is not re-written before forwarding the access requestmessage to another server. However, in row 53, the entry is “n@bti.com”.This is an instruction to re-write the user identifier from the form n/dto the form n@d and to use bti.com as the value for the domain part ofthe user identifier.

Although not shown in FIG. 5, there can be two further columns, whichare similar to column 43, which contain instructions for re-writing theuser identifier for internal use within the proxy server 24 forauthentication and accounting.

After consulting column 43, the proxy server 24 then consults column 44(headed Authentication Route) and column 45 (headed Accounting Route).These contain instructions for the route through to be followed forauthentication and accounting. In the present example, there are fourpossible routes, namely routes 1-4. For example, it will be seen that,in row 51, both the authentication and accounting routes are route 2. Inrow 54, the authentication route is route 3 but the accounting route isroute 2. Thus the accounting and authentication routes can be different.The details for each route are set out in the table shown in FIG. 6 andthis table will now be described.

Referring now to FIG. 6, it will be seen that the table has four columns61-64. Column 61 (headed Route) gives the number of the route. It willbe seen that there are four rows 71-74 corresponding to the fourdifferent routes. Generally, the number of rows will be equal to thenumber of possible routes.

The column 62 (headed Primary) gives the name of the server which is themain or first choice for performing the relevant (authentication oraccounting) operation. Column 63 (headed Secondary) and column 64(headed Tertiary) give the first alternative and the second alternativechoice for performing the relevant operation in the event that theserver specified in column 62 is unable to perform the operation.

Thus, in row 71 (route 1), it will be seen that the first choice forperforming the relevant operation is the server A. If the server A isunable to perform the operation, then as a default procedure, the serverB is instructed to perform the relevant operation. If the server B isunable to perform the relevant operation, then as a further default, asindicated in column 64, the access request is rejected.

As shown in row 72 (route 2), it will be seen that the entry for thefirst choice for performing the relevant operation is marked “local”.This is an instruction to perform the relevant operation in the proxyserver 24 itself. In the case of route 2, there are no default oralternative choices for performing the relevant operation.

In the case of row 73 (route), it will be seen that the entry for thefirst choice for performing the relevant operation is marked “accept”.This is simply an instruction to accept the access request.

In row 74 (route 4), it will be seen as the first choice for performingthe relevant operation for route 4 is server C. As shown in the entry incolumn 63, it will be seen that the default action is to accept theaccess request.

Referring back to FIG. 5, it is to be appreciated that further columnscould be added to provide further instructions for processing an accessrequest message. For example, there could be an instruction for the NAS16 to apply a filter. This would have the effect of preventing the enduser from accessing certain addresses in the Internet 12.

The procedure for handling an access request message will now besummarised with reference to the flow chart shown in FIG. 7.

Initially, in step 80, the details relating to the end user are comparedwith each one of a set of patterns in turn until a match is found. Asdescribed above, this is performed by using the entries in column 41 ofthe table shown in FIG. 5. Then, in a step 81, the relevant rule isidentified. In the example shown in FIG. 5, this is performed bycomparing the details relating to the end user with a specified valuefor one attribute for each rule in turn until a match is found. Then, instep 82, if appropriate, the user identifier is re-written beforeforwarding it to another server using the entries set out in column 43.In steps 83 and 84, the access request message is processed using theauthentication route as set out in column 44 and the accounting route asset out in column 45.

The procedure described with reference to FIGS. 5 to 7 can also be usedwith the network access arrangement shown in FIG. 1. However, when soused, the option of forwarding an access request to another server isclearly not available.

Referring now back to FIG. 5, each of rows 51 to 55 contains a rule fora particular access service provided by the NAS 16. The columns 44 and45 contain the routes for performing authentication for the variousservices. Thus, for the service of row 51, the primary choice for bothauthentication and accounting is the proxy server 24. In the case of theservice of this row, there is no alternative choice or default procedurefor authentication and accounting. In the case of the service of row 52,the primary choice for both authentication and accounting is theauthentication server C. In the case of the service of this row, if theproxy server 24 sends an access request message to the authenticationserver C but does not receive a response, the proxy server 24 proceedsto the secondary choice, specified in column 63 of FIG. 6, for dealingwith the access request message from the NAS 16. In this case, thedefault action is to accept the access request and therefore to send anaccess accept message back to NAS 16.

In the case of the service of row 53, the primary choice for bothauthentication and accounting is the authentication server A. If theproxy server 24 does not receive a response from an access requestmessage which it sends to authentication server A, then it proceeds tothe secondary choice specified in column 63 of FIG. 6. In this case, thesecondary choice or default action for dealing with the access requestmessage from NAS 16 is to forward the access request message to theauthentication server B.

In the case of the service of row 54, the primary, and only, action fordealing with authentication, is to accept the access request message. Inthe case of the service of row 54, the primary and only action foraccounting, is to handle accounting locally in the proxy server 24.

In the case of the services of rows 53 and 52, there will be occasionswhen the primary choice for authentication and accounting fails. Thismay be caused, for example, by a brief interruption in the transmissionlink between the proxy server 24 and either the server A or the serverC, or a brief failure or overload in either server A or server C. Insuch situations, the default action specified in column 63 should besufficient to ensure that a satisfactory response can be sent by theproxy server 24 to the NAS 16.

However, in the case of the services of rows 53 and 52, there will beoccasions when either server A or server C fails to respond to an accessrequest message from the proxy server 24 over a prolonged period. Thiscould be caused either by a failure in the communications link betweenthe proxy server 24 and either server A or server C or a completefailure in either server A or server C. If such a failure does occur,then access request messages for the corresponding service will bequeued in proxy server 24 before they are handled by proxy server 24 inaccordance with the default action. If this happens, then the queue ofaccess request messages in proxy server 24 for the relevant service willlengthen and proxy server 24 will be effectively saturated with theserequests. Consequently, the delay in sending a response to NAS 16 willincrease to the point at which it reaches the time out period of NAS 16for receiving a response. If this happens, NAS 16 will apply its owndefault action which is to refuse access requests for the relevantservice. Clearly, this is unsatisfactory for the end users.

There will now be described with reference to FIG. 8 a process which isperformed in the proxy server 24 for overcoming this problem. Theprocess is performed for each access request message which relates to aservice for which the primary choice for handling the authenticationrequest message from the NAS 16 is to forward it to another server and aseparate process is performed for each such service. For each accessrequest message from the NAS 16, this process is performed after step 81shown in FIG. 7.

Referring now to FIG. 8, this process uses two software counters, namelycounter A and counter B. Each of these counters is initially set tozero.

For each access request message, in an initial step, the value ofcounter A is compared with a threshold value in a step 100. If the valueof counter A is below the threshold value, then in a step 101, theaccess request message is forwarded to the appropriate authenticationserver, for example server A for server B. Then, in a step 102, theproxy server waits for a response from the appropriate authenticationserver. If a response is received, then counter A is decremented in astep 103 and the process then ends for this access request message.

If in step 102 no response is received from the relevant authenticationcounter, then the default action is followed in a step 103. As mentionedabove, the default actions are shown in column 63 in FIG. 6. After step103, counter A is incremented in a step 104 and the process then endsfor this access request message.

In step 100, on the first occasion that it is found that the value incounter A equals the threshold value, then counter B is set to athreshold value. As will be seen, this threshold value represents thenumber of access request messages for which default action is followedbefore another attempt is made to forward an access request message tothe relevant authentication server.

After step 100, the default action is followed in a step 105 and thecounter B is then decremented in a step 106. As mentioned above, thedefault actions are shown in column 63 in FIG. 6.

Then, in a step 107, if the value in counter B does not equal zero, theprocess ends for this request message. If the value in counter B doesequal zero, then in a step 108, counter A is decremented. The result ofthis is that the next access request message will be forwarded to therelevant authentication server. The process then ends for this accessrequest message.

Thus, in the normal course of events, the value in counter A fluctuatesup and down between zero and its threshold value as long as the relevantauthentication server is handling nearly all of the access requestmessages which are forwarded to it. However, when there is a failure,then the default action is followed for a number of access requestmessages equal to the threshold value of counter B.

As a result of following this process, in the event that one of theauthentication servers fails to respond for a prolonged period, theproxy server 24 does not saturate and sends a response to the NAS 16 foreach access message before the time out period is reached.

Although the process shown in FIG. 8 has been described with referenceto handling access request messages, it can also be used for accounting.In order to achieve this, the default action shown in step 105 includesthe default action for accounting as well as for authentication.

Referring back to FIG. 4, the organisation which manages the networkaccess server 16 and the proxy server 24 may be separate from theorganisations which manage the authentication servers A, B and C. Anorganisation which manages one of the servers A, B or C may wish, onsome occasions, to specify a filter in an access accept message. Where afilter is applied by the network access server 16, then traffic from theend users computer 10 to the Internet 12 is restricted to one or morespecified addresses.

The RADIUS protocol mentioned above does include a field for specifyinga filter. Unfortunately, the vendors of network access servers tend toprovide their own proprietary methods. Consequently, it is usually notpossible to specify a filter using the attribute field in the RADIUSprotocol and this creates difficulties in specifying a filter in anaccess accept message transmitted by one of the authentication serversA, B and C.

Also, the organisations which manage the servers A, B and C may wish tohave the opportunity to specify both static and dynamic filters. Astatic filter consists of a named item which has to be configured andagreed prior to use. For example, a static filter might be configured torestrict access just to a registration server. In contrast, a dynamicfilter does not have to be agreed in advance and specifies that accessis to be restricted to either a single address or a range of addresses.Unfortunately, the attribute field in the RADIUS protocol does not coverthe possibility of specifying a dynamic filter. Consequently, it isdifficult to specify a dynamic filter in an access accept messageproduced by one of the servers A, B or C.

There will now be described a process which permits the authenticationservers A, B and C to specify both static and dynamic filters in anaccess accept message and without having knowledge of the type ofnetwork access server which will be used to make a connection between anend-user's computer and the Internet.

In this process a standard protocol is agreed between the organisationwhich manages the proxy server 24 and the organisations which manage theservers A, B and C. This protocol permits the authentication servers A,B and C to specify both static and dynamic filters. It specifies theformat for each type of filter. In this example, an access acceptmessage can specify either a static filter or up to 10 dynamic filters.It cannot specify both static and dynamic filters. As will be explained,the proxy server 24 translates a filter specified in an access requestmessage in to the protocol used by the network access server 16.Although FIG. 4 shows only a single access server 16, in a morecomplicated arrangement, the proxy server 24 may receive access requestmessages from several clusters of network access servers provided byseveral different vendors.

In this process, on receiving an accept message containing a filteridentifier, the proxy server 24 performs the operation shown in FIG. 9.

Referring now to FIG. 9, in a step 150, the proxy server 24 receives anaccess accept message containing a filter identifier.

Then, in a step 151, the proxy server 24 checks that the filteridentifier is valid. As mentioned above, a mixture of static and dynamicfilters is not permitted. Therefore, if a filter identifier contains amixture of static and dynamic filters, it is found invalid. Also, asmentioned above, if a filter identifier specifies more than 10 dynamicfilters it is found invalid. Also, the proxy server 24 checks that eachfilter is specified in the correct format. If an incorrect format isused, then the filter identifier is found invalid.

If the filter identifier is valid, then the proxy server 24 performsstep 152. In this step, it translates the filter identifier from thestandard protocol to the protocol used by NAS 16. For example, in thestandard protocol, each dynamic filter is specified in the form;

a.b.c.d/n.

In this format “a.b.c.d” represent an IP address and “n” represents thenumber of bits of that address which are to be enforced. Thus, if n=32,the whole address is to be enforced. If n has a value less than 32, thenonly the appropriate part of the address is to be enforced.

In the case of network access servers manufactured by Cisco, a dynamicfilter includes the term: “a.b.c.d.X.Y.Z.T”. The interpretation of thisis that access is to be restricted to an address range, the lower limitof which is X.Y.Z.T and the upper limit of which is a.b.c.d.

After performing the translation in step 152, in a step 153 the accessaccept message is forwarded to the NAS 16 with a filter identifier inthe protocol used by NAS 16.

If in step 151 it is found that the filter identifier is not valid, thena default action is applied in a step 154. The default action can beagreed between the organisation which manages the proxy server 24 andthe relevant authentication server a, b or c in advance. The twopossibilities for the default action are to forward an access acceptmessage without a filter or to forward an access reject message to thenetwork access server 16.

This process has the advantage that the servers A, B and C can specifyfilters without any knowledge of the type of network access server whichwill be used to form a connection. Also, both static and dynamic filterscan be specified.

Referring now to FIG. 10, there is shown another arrangement forconnecting computers operated by end users to the public Internet. Thisarrangement includes two clusters of network access servers 200, 201connected to a private data network 202. The private data network 202 issimilar to the private data network 20 described with reference toFIG. 1. Two authentication servers 203, 204 and a home gateway 205 arealso connected to the private data network 202.

As will be described below, the home gateway 205 can connect computersoperated by end users to the public Internet 206. The home gateway 205is also connected to a second private data network 210, which is similarto the private data network 20 described with reference to FIG. 1. Aproxy server 211 and two authentication servers 212 and 213 are alsoconnected to the data network 210.

In this example, the network access servers 200, 201, the authenticationservers 203, 204, the home gateway 205 and the proxy server 211 aremanaged by one organisation and the two authentication servers 212 and213 are managed by separate organisations.

The network access servers 200, 201 connect computers operated by someend users directly to the public Internet. However, computers operatedby other end users are connected to the public Internet via the homegateway 205.

When one of the network access servers 200, 201 receives an accessrequest from a computer operated by an end user, it forwards the accessrequest to one of the authentication servers 203, 204. If the computermaking the request is to be connected to the public Internet via thehome gateway 205, then the relevant authentication server 203 or 204sends an instruction to the relevant network access server to build aconnection or tunnel to the home gateway 205 for the computer which hasmade the access request. The network access server then builds a tunnelto the home gateway 205. There are a number of different tunnellingprotocols to do this. One of these is the so called L2TP (Layer TwoTunnelling Protocol). This protocol is supported by most network accessserver vendors.

After forming the tunnel to the home gateway 205, the network accessserver then forwards the access request message to the home gateway 205.The home gateway 205 is also a virtual network access server. Onreceiving the access request, it forwards it to the proxy server 211.The proxy server 211 then selects one of the authentication servers 212,213 and forwards the access request to the selected authenticationserver. The selected authentication server 212 or 213 processes theaccess request and sends a response to the proxy server 211. Theresponse will be either an access accept or access reject message. Theproxy server 211 then forwards a response to the home gateway 205. Thehome gateway 205 then either allows or denies the access request inaccordance with a response from the proxy server 211. If the homegateway 205 allows the request, then the end user is connected to theInternet 206 through relevant one of the network access servers 200 or201 and the home gateway 205.

In the arrangement shown in FIG. 10, the proxy server 211 can performthe processes which have been described above with reference to FIGS. 5to 9.

1. A method of processing requests at an access server arrangement for adata terminal operated by an end user to access a data network, saidmethod comprising: receiving requests from data terminals at the accessserver arrangement for access to the data network; comparing eachrequest with a table comprising a plurality of different rules andidentifying a matching rule comprising a primary choice procedure and adefault procedure, the primary choice procedure specifying a remoteauthentication server; in the event that a predetermined criterion,which is indicative of a possibility of a failure relating to theauthentication server specified in the primary choice procedure of thematched rule, is not satisfied: (i) attempting to forward the accessrequest to the authentication server specified in the matched rule; (ii)if a response is received from the authentication server, dealing withthe access request in accordance with the response; and (iii) if aresponse is not received from the authentication server, dealing withthe access request in accordance with the default procedure specified inthe matched rule; and in the event that the predetermined criterion,which is indicative of a possibility of a failure relating to theauthentication server specified in the primary choice procedure of thematched rule, is satisfied, dealing with each access request matchingthe matched rule in accordance with said default procedure, as specifiedin the matched rule, for a predetermined number of times and thenattempting to forward a subsequently received access request, matchingthe same rule, to the authentication server specified in the primarychoice procedure of the matched rule.
 2. A method as in claim 1, whereinthe table comprises a plurality of rules specifying a plurality ofauthentication servers and wherein a request is matched to a rule inaccordance with the value of at least one attribute contained in theaccess request and further including: selecting an authentication serverfrom a plurality of authentication servers in accordance with the valueof at least one attribute contained in the access request; and in saidstep of attempting to forward the access request, making an attempt toforward the access request to the selected authentication server.
 3. Amethod as in claim 1, in which the network access arrangement includes aproxy server, the proxy server being responsible for forwarding anaccess request to an authentication server, receiving any response fromthe authentication server, and, if appropriate, handling an accessrequest in accordance with the default procedure.
 4. A method as inclaim 1, in which the predetermined criterion is satisfied if there arerepetitive failures to receive a response from an authentication server.5. A method as in claim 1, which further includes: if a response is notreceived from an authentication server, changing the value held in acounter by one unit in one direction; and if a response is received froman authentication server, changing the value held in the counter by oneunit in the other direction; and the predetermined criterion is reachedwhen the value held in the counter has progressed in said one directionto a predetermined threshold.
 6. A method as in claim 5, in which, inthe event that the counter has reached said predetermined threshold, themethod further includes performing the default procedure for apredetermined number of times, then changing the value held in thecounter by one unit in the other direction, then making an attempt toforward the next access request to the authentication server.
 7. Anetwork access server configured to operate according to the method ofclaim
 1. 8. A network including at least one network access serveraccording to claim 7 and at least one of said authentication servers. 9.An access server arrangement for controlling access by a data terminaloperated by an end user to access a data network, said access serverarrangement comprising: receiving means for receiving requests from dataterminals at the access server arrangement for access to the datanetwork; and processing and transmitting means for comparing eachrequest with a table comprising a plurality of different rules andidentifying a matching rule, comprising a primary choice procedure and adefault procedure, the primary choice procedure specifying a remoteauthentication server and, in the event that a predetermined criterion,which is indicative of a possibility of a failure relating to theauthentication server specified in the primary choice procedure of thematched rule, is not satisfied; (i) attempting to forward the accessrequest to an authentication server specified in the matching rule; (ii)if a response is received from the authentication server dealing withthe access request in accordance with the response; and (iii) if aresponse is not received from the authentication server dealing with theaccess request in accordance with a default procedure specified in thematched rule; and in the event that the predetermined criterion issatisfied, dealing with each access request matching a particular rulein accordance with the default procedure specified in the matched rulefor a predetermined number of times and then attempting to forward asubsequently received access request matching the same rule to theauthentication server specified in the matched rule wherein the tablecomprises a plurality of different rules.
 10. A network including atleast one access server arrangement as in claim 9 and one or moreauthentication servers operable to receive forwarded access requestsfrom the access server arrangement.